docs(actual-budget): manage E2EE password in OpenBao + document manual enable#2476
Merged
Merged
Conversation
…l enable Actual Budget's end-to-end encryption is a client-side, password-derived feature: the client derives the key locally and the sync-server never sees the password or key (that is what makes it end-to-end). There is no ACTUAL_* env or server endpoint to enable it, so it cannot be turned on declaratively. What can be declarative — and matters most — is the password of record. Seed an OpenBao path apps/actual-budget/encryption (create-only placeholder, mirroring the enablebanking seed) as the durable DR store for the password; nothing in-cluster reads it back because only a client can use it. Document the one-time manual enable step in the app README and add the password as a root of trust in docs/dr/crypto-custody.md, with the lost-password = unrecoverable warning. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis change adds Kubernetes manifests to seed an Actual Budget end-to-end-encryption password placeholder into OpenBao via a create-only PushSecret, and wires these resources into the vault-seed kustomization. Documentation is added/updated in the disaster-recovery crypto-custody guide and a new Actual Budget base README, describing the password's client-side derivation, storage location, custody recommendations, and leak/loss incident handling. Changes
Sequence Diagram(s)sequenceDiagram
participant Kustomization
participant PlaceholderSecret
participant PushSecret
participant OpenBao
Kustomization->>PlaceholderSecret: include secret-actual-budget-encryption-placeholder.yaml
Kustomization->>PushSecret: include push-secret-seed-actual-budget-encryption.yaml
PushSecret->>PlaceholderSecret: read password value
PushSecret->>OpenBao: push to apps/actual-budget/encryption (IfNotExists)
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Contributor
Author
@coderabbitai review |
|
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
|
🎉 This PR is included in version 1.100.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why: We want Actual Budget's end-to-end encryption managed the same declarative way as everything else. But Actual's E2EE is client-side and password-derived by design — the server never sees the key — so there is no server switch to enable it, and there shouldn't be. The real risk to manage is a lost password: it makes the budget permanently unrecoverable.
What: Declares the E2EE password as a root of trust — seeds an OpenBao path (
apps/actual-budget/encryption, create-only placeholder, mirroring the Enable Banking seed) as the durable DR store, and documents the one-time manual "Enable encryption" step in the app README plus a custody entry in the DR crypto-custody doc. Nothing in-cluster consumes the password (only a client can use it); OpenBao is purely the record so it can't be lost.No behaviour change to the running app — seed + docs only.